Resolved #307 Resolved #308 - Updated documentation based on implementation docs and clarified when an item should be created#310
Conversation
solind
left a comment
solind
left a comment
There was a problem hiding this comment.
I'm not quite sure about these documentation changes. In particular, those that infer something about the existence of ntuser_objects based on state entities.
| <xsd:element name="name" type="oval-def:EntityStateStringType" minOccurs="0"> | ||
| <xsd:annotation> | ||
| <xsd:documentation>This element describes the name of a value of a registry key.</xsd:documentation> | ||
| <xsd:documentation>Note: The name not existing on the target does not impact the overall existence of the ntuser_item.</xsd:documentation> |
There was a problem hiding this comment.
If there is an item with a corresponding name, the object will be said to exist.
Anyway, this is documentation for the state entity. If the state specifies a name that doesn't match any item, then no items will match that state. The effect on existence comes into play only if the state is used to filter an object or set.
| <xsd:element name="logged_on" type="oval-def:EntityStateBoolType" minOccurs="0"> | ||
| <xsd:annotation> | ||
| <xsd:documentation>The logged_on element describes if the user account is currently logged on to the computer.</xsd:documentation> | ||
| <xsd:documentation>This can be determined by comparing the SID’s against those populated in HKEY_USERS</xsd:documentation> |
There was a problem hiding this comment.
The active user logon sessions can also be determined using the WMI classes Win32_LoggedOnUser and Win32_LogonSession. I'm not sure whether the presence of a hive under HKEY_USERS is completely reliable for the purpose of whether the user should actually be considered "logged on".
I recall we considered interactive and remote interactive session types to be logged on.
| <xsd:element name="days_since_last_logon" type="oval-def:EntityStateIntType" minOccurs="0" maxOccurs="1"> | ||
| <xsd:annotation> | ||
| <xsd:documentation>The last_logon data, converted to days and then rounded down to the nearest integer (floor function). If the account is determined to be currently logged in, this date should be reported as 0.</xsd:documentation> | ||
| <xsd:documentation>The last_logon data which can be obtained from the LocalProfileLoadTimeHigh and LocalProfileLoadTimeLow values, converted to days and then rounded down to the nearest integer (floor function). If the account is determined to be currently logged in, this date should be reported as 0.</xsd:documentation> |
There was a problem hiding this comment.
Where are these obtained from? Registry values somewhere under HKLM?
Data can also be obtained from the WMI table Win32_NetworkLoginProfile.
| <xsd:element name="enabled" type="oval-def:EntityStateBoolType" minOccurs="0"> | ||
| <xsd:annotation> | ||
| <xsd:documentation>The enabled element describes if the user account is enabled or disabled.</xsd:documentation> | ||
| <xsd:documentation>Note: For domain users, if a domain controller is not available, this will not return data. If using this data for a filter to include enabled accounts, it’s recommended to exclude accounts that are have been determined to be disabled, vs including ones that are enabled, as the later may filter out accounts for which the domain controller could not return data.</xsd:documentation> |
There was a problem hiding this comment.
I think we'd have to say that the element would be status="not_collected" (IIRC) if the domain server is unavailable, which (for good or ill) has documented evaluation effects. Or, it could have an error status.
| <xsd:element name="filepath" type="oval-def:EntityStateStringType" minOccurs="0"> | ||
| <xsd:annotation> | ||
| <xsd:documentation>This element describes the filepath of the ntuser.dat file.</xsd:documentation> | ||
| <xsd:documentation>The existance of each ntuser.dat file determines the overall ntuser_item existence.</xsd:documentation> |
There was a problem hiding this comment.
I hate to get into semantics, but I think you mean to be talking about the existence of the object, not the item. The object exists if all its criteria are satisfied by one or more items discovered on the target machine.
| <xsd:documentation> iii. Include Local and Domain User SIDs by including subkeys match the format of S-1-5-21-<number*gt;-<number*gt;-<number*gt;-<number*gt;</xsd:documentation> | ||
| <xsd:documentation> c. Obtain ntuser filepath from the ProfileImagePath value of 'human' profiles</xsd:documentation> | ||
| <xsd:documentation>2. Creating ntuser items</xsd:documentation> | ||
| <xsd:documentation>If the filepath obtained from the ProfileImagePath exists on the target system, create a ntuser_item with a status of 'exists'</xsd:documentation> |
There was a problem hiding this comment.
This is basically saying that all NTUSER objects always exist, assuming there is at least one user profile on the target machine (there should always be at least one). I don't think that's right, but... it's been a long time.
| <xsd:documentation>The username entity holds a string that represents the name of a particular user. In Windows, user names are case-insensitive. As a | ||
| result, it is recommended that the case-insensitive operations are used for this entity. In a domain environment, users should be identified in | ||
| the form: "domain\user name". For local users use: "computer name\user name".</xsd:documentation> | ||
| <xsd:documentation>Note: When gathering the built-in Guest and build-in Administrator, they may not resolve and may need to have the ComputerName prepended to it.</xsd:documentation> |
There was a problem hiding this comment.
The built-in guest and administrator accounts may actually be renamed. They are really only recognizable using their SIDs. I believe the username convention here should follow those used for other Windows user objects.
2 participants
Updated docs to clear document how to go about determining which ntuser.dat files should be included, and when to create a ntuser_item